-
-
Notifications
You must be signed in to change notification settings - Fork 698
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added the 'any' and 'all' flags for 'keys' assertion, with 'all' being the default behavior #313
Conversation
}); | ||
if (!flag(this, 'any') && !flag(this, 'all')) { | ||
flag(this, 'all', true); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure this is an entirely safe thing to do. It will set the flag for any future assertions - which could lead to subtle bugs, should we ever extend the any
or all
flags. Might be better to just var these up as Booleans at this point I believe.
Great work @cjqed! It'd be nice if this PR also featured extending the documentation for With this and the above comment addressed, I'll be overjoyed to merge this 😄 |
Thanks for the comments @keithamus . Keys just uses bools for any and all now and I redid the documentation for keys. |
Just kidding, now it's good. Had an error about the behavior of "contains" in the documentation. |
Great job @cjqed! It's so close to being perfect for me - but I feel like the documentation could be a little more explicit. Reading through it, it doesn't seem to make a solid distinction between That is definitely my last comment now 😸 |
@keithamus when docs are to your liking, you have my 👍 |
9f67cdf
to
a0743b0
Compare
@keithamus No worries on doc rewrite requests, I understand that documentation for something like an assertion library needs to be really explicit. Try that, what do you think? Also, I rebased from my other branch, so merging this last should lead to no conflicts. |
@cjqed the documentation is looking great now, but I think the rebase has introduced the commits from your other branch. I recommend running the following in your repo: git remote add upstream https://github.com/chaijs/chai
git fetch -p
git rebase upstream/master Optionally, which would be pretty sweet, you could do a |
4815b6f
to
a0743b0
Compare
…fault behavior Extended keys documentation and set bools instead of changing flags in the keys assertion Miswrote in keys documentation, corrected mistake Edited documentation for keys to better match how it interacts with contains and have
a0743b0
to
e0e0608
Compare
That should do it. |
🎉 |
Added the 'any' and 'all' flags for 'keys' assertion, with 'all' being the default behavior
This should resolve #254 and the unintuitive behavior of the
keys
assertion. See the tests for more details, but in a nutshell, the following pass:And the following fail:
To preserve backward compatibility, using neither any nor all will default you to all. Since no previous tests failed, I'm assuming this worked but let me know if anything sticks out to you.
Thanks!